Radio access technologies for cellular mobile networks are continuously being evolved to meet the future demands for higher data rates, improved coverage and capacity. Example of recent evolutions of the Wideband Code Division Multiple Access, WCDMA, technology is High-Speed Packet Access, HSPA. Currently further evolutions of the 3G systems, 3G Long Term Evolution, LTE, including new access technologies and new architectures are being developed within the 3rd Generation Partnership Project, 3GPP, standardisation body.
One of the targets for LTE access technology is to improve set-up times, i.e. the User Equipment, UE, sometimes called mobile station or mobile terminal, shall be able to connect to the network and initiate a session quickly. The UE can be in one of two Radio Resource Control, RRC, states, RRC_IDLE or RRC_CONNECTED. When the UE is in RRC_CONNECTED state the UE has an RRC connection as opposed to when the UE is in RRC_IDLE. This means that a session can be initiated quickly without a RRC connection procedure. In a base station (e.g. NodeB or eNodeB) implementation it is therefore desirable to keep a user in RRC_CONNECTED state as long as possible. The base station must then be able to support a large number of users in this state. For example it could be desirable to keep up to 2000 UEs in RRC_CONNECTED per cell. In any base station implementation the number of users that can be handled in the scheduling process is limited by processing, hardware and/or memory capability. This means that only a subset of all users can be candidates for scheduling. The UEs that are in RRC_CONNECTED and are also candidates for scheduling are said to be in “session active” state. For example, a base station implementation could support 400 users in “session active”.
When the number of UEs requesting sessions exceeds what can be handled in the base station implementation, session requests must be denied. However, the “session active” state is only visible internally in the base station implementation and is not known in the UE. It is therefore not possible to deny a UE to perform a session request that is initiated in the UE. In the UE a session request can be initiated through a Random Access Channel, RACH, procedure or, in case scheduling request resources are available through a scheduling request, SR.
Both Uplink, UL, and Downlink, DL, resource assignment is performed by the scheduler situated in the base station, eNodeB. The basic uplink scheduling concept is described below. The Physical Uplink Shared Channel, PUSCH, is a dynamically scheduled channel where resources are assigned dynamically on the Physical Downlink Control Channel, PDCCH. The SR channel is a dedicated semi-statically assigned channel where the UE can quickly acquire for resources on the PUSCH, the UE must however be synchronised in the UL to be able to use the SR. After a longer time of inactivity the UE typically loses UL synchronisation and the SR resources are typically revoked. In this case the UE must use a RACH procedure to initiate a new session.
To inform the UL scheduler of the UE's momentary traffic demands the standard will also support buffer status reports to indicate how much data there is to transmit and of what priority. Alternatively, the scheduler may configure the UE to always send from the highest prioritised data flow. In this case it is sufficient to monitor the priority of the transmitted data. The scheduler monitors the users' traffic demands and assigns resources accordingly. The scheduler informs the users of the scheduling decision by transmitting resource assignments on the PDCCH.
The random access procedure is performed for the following five events:                1. Initial access from RRC_IDLE;        2. Initial access after radio link failure;        3. Handover requiring random access procedure;        4. DL data arrival during RRC_CONNECTED requiring random access procedure;                    E.g. when UL synchronisation status is “non-synchronised”;                        5. UL data arrival during RRC_CONNECTED requiring random access procedure;                    E.g. when UL synchronisation status is “non-synchronised” or there are no dedicated scheduling request channels available.                        
The invention relates to the fifth event, i.e. UL data arriving during RRC_CONNECTED and the UE is either non-synchronised or has no scheduling request channel available. In this case a contention based RACH procedure is used.
The contention based random access procedure involves four steps:                1. Random Access Preamble on RACH in uplink (from UE to eNodeB);        2. Random Access Response on Downlink Shared Channel, DL-SCH (from eNodeB to UE);        3. First scheduled UL transmission on Uplink Shared Channel, UL-SCH (from UE to eNodeB;        4. Contention Resolution on DL-SCH (from eNodeB to UE).        
The contention based RACH procedure is subject to collisions from other users in the cell. As the number of users (all users in RCC_CONNECTED) that could potentially initiate a RACH procedure increases, the probability of collisions on the RACH channel increases and performance degrades quickly. It is therefore important not to have a too high load on the RACH channel, i.e. not too many procedures initiated per UE.
Normally, a session can proceed after the RACH procedure is performed. However, in case the base station cannot handle more users due to limited resources not all users can be scheduled further and the base station must prioritise between users depending on the priority of the data.
A possible solution is to let the UE initiate a RACH procedure regularly, for example related to Transmission Time Interval, TTI, as long as there is data in the UE transmit buffers but the UE does not have an uplink scheduling request resource or does not have UL synchronisation. This solution however has certain drawbacks as illustrated in FIGS. 1 and 2.
FIG. 1 illustrates that if the UE is allowed to repeat the RACH procedure frequently, there will be a high load on the RACH channel and the PDCCH channel. FIG. 2, on the other hand, illustrates that if the UE only is allowed to repeat the RACH procedure seldom, there is risk for a long delay before the scheduler is made aware of high priority data.
The procedure illustrated in both of FIGS. 1 and 2 starts with the UE obtaining data of lower priority and then initiating a RACH procedure 100 by transmitting a RACH preamble to the base station, 102. At this point the scheduler does not know the priority of the data and grants, 104, the UE enough resources so that the UE can respond with at least a buffer status report, BSR, 106. Suppose now, that the base station is close to the maximum number of users that is can support in session active and based on the BSR the base station decides not to schedule the UE further. The base station then prioritizes other users based on the BSR, 108.
If, according to the scenario of FIG. 1, the UE is allowed to repeat the RACH procedures regularly, 110, 120, this will cause an unnecessary high load on the RACH channel and the PDCCH channel, 112. It will also cost unnecessary UE power. In the illustrated example, high priority data arrives after the third RACH procedure 120. In the fourth procedure 130 the scheduler is made aware of the high priority data.
FIG. 2 illustrates that if the UE, on the other hand, is only allowed to repeat the RACH procedure seldom, 200, 210, there is risk for a long delay. In this example, the high priority data arrives after the second RACH procedure 210, but the base station is not made aware until the third procedure 220, causing the delay 214. This data could for example consist of an urgent handover report that is unnecessarily delayed.